home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 2002 November / SGI Freeware 2002 November - Disc 3.iso / dist / fw_sharutils.idb / usr / freeware / info / remsync.info.z / remsync.info (.txt)
GNU Info File  |  2000-04-13  |  29KB  |  547 lines
  1. This is Info file remsync.info, produced by Makeinfo version 1.68 from
  2. the input file remsync.texi.
  3. INFO-DIR-SECTION Shell Archive utilities
  4. START-INFO-DIR-ENTRY
  5. * Remsync: (remsync).                   Synchronize remote files.
  6. * mail-files: (remsync)mail-files invocation.   Send files to remote site.
  7. * mailshar: (remsync)mailshar invocation.       Make and send a shell archive.
  8. END-INFO-DIR-ENTRY
  9.    This file documents the `remsync' command and friends, which have
  10. the purpose of synchronizing remote directory trees using email.
  11.    Copyright (C) 1994 Free Software Foundation, Inc.
  12.    Permission is granted to make and distribute verbatim copies of this
  13. manual provided the copyright notice and this permission notice are
  14. preserved on all copies.
  15.    Permission is granted to copy and distribute modified versions of
  16. this manual under the conditions for verbatim copying, provided that
  17. the entire resulting derived work is distributed under the terms of a
  18. permission notice identical to this one.
  19.    Permission is granted to copy and distribute translations of this
  20. manual into another language, under the above conditions for modified
  21. versions, except that this permission notice may be stated in a
  22. translation approved by the Foundation.
  23. File: remsync.info,  Node: Top,  Next: Overview,  Prev: (dir),  Up: (dir)
  24. `remsync'
  25. *********
  26.    `remsync' allows for remote synchronization of directory trees,
  27. using electronic mail.
  28.    The current `remsync' release is 1.3.  This is an alpha state
  29. product, and this documentation is still sketchy.
  30. * Menu:
  31. * Overview::            Overview of `remsync' and friends
  32. * Remsync::             Specifications of program `remsync'
  33. * Services::            Specifications of other service programs
  34. * Formats::             Related file formats
  35. * Miscellaneous::
  36.  -- The Detailed Node Listing --
  37. Overview of `remsync' and friends
  38. * Internals::           How `remsync' works
  39. * Quick start::         Quick start at using `remsync'
  40. Quick start at using `remsync'
  41. * Invoking remsync::    The `remsync' command and arguments
  42. Specifications of program `remsync'
  43. * Invoking remsync::    The `remsync' command and arguments
  44. * Conveniences::        Automatic mechanisms in the `remsync' program
  45. * Commands::            Commands for `remsync'
  46. The `remsync' command and arguments
  47. * Conveniences::        Automatic mechanisms in the `remsync' program
  48. * Commands::            Commands for `remsync'
  49. Specifications of other service programs
  50. * Invoking mailshar::   The `mailshar' command and arguments
  51. * Invoking mail-files::  The `mail-files' command and arguments
  52. * Invoking find-mailer::  The `find-mailer' command and arguments
  53. Related file formats
  54. * Xremsync::            Format of the `.remsync' file
  55. * Package::             Format of transiting packages
  56. Various considerations
  57. * News::                Using News distribution instead?
  58. * Previous::            Documentation for obsolete scripts
  59. Documentation for obsolete scripts
  60. * mailsync::            mailsync
  61. * resync::              resync
  62. File: remsync.info,  Node: Overview,  Next: Remsync,  Prev: Top,  Up: Top
  63. Overview of `remsync' and friends
  64. *********************************
  65.    The `remsync' program allows for transmitting, over email, selected
  66. parts of directories for trying to maintain up-to-date files over many
  67. sites.  It sends out and processes incoming specially packaged files
  68. using `shar', `tar', `gzip' and electronic mail programs.
  69.    There is no *master* site, each site has an equal opportunity to
  70. modify files, and modified files are propagated.  Among many other
  71. commands, the `broadcast' command sends an update package from the
  72. current site to all others, the `process' command is used to apply
  73. update packages locally after reception from remote sites.
  74.    The unit of transmission is whole files.  For now, whenever a module
  75. is modified, it is silently synchronized only if it has been modified at
  76. only one place.  The merging has to be done at the site where the
  77. discrepancy is observed, from where it is propagated again.
  78. * Menu:
  79. * Internals::           How `remsync' works
  80. * Quick start::         Quick start at using `remsync'
  81. File: remsync.info,  Node: Internals,  Next: Quick start,  Prev: Overview,  Up: Overview
  82. How `remsync' works
  83. ===================
  84.    How does `remsync' keep track of what is in sync, and what isn't?
  85. *Note Xremsync::, for a the documentation on the `.remsync' file
  86. format.  I understand that a mere description of the format does not
  87. replace an explanation, but in the meantime, you might guess from the
  88. format how the program works.
  89.    All files are summarized by a checksum, computed by the `sum'
  90. program.  There are a few variants of `sum' computing checksums in
  91. incompatible ways, under the control of options.  `remsync' attempts to
  92. retrieve on each site a compatible way to do it, and complains if it
  93. cannot.
  94.    `remsync' does not compare dates or sizes.  Experience shown that the
  95. best version of a file is not necessarily the one with the latest
  96. timestamp.  The best version for a site is the current version on this
  97. site, as decided by its maintainer there, and this is this version that
  98. will be propagated.
  99.    Each site has an idea of the checksum of a file for all other sites.
  100. These checksums are not necessarily identical, for sites do not
  101. necessarily propagate to all others, and the propagation network maybe
  102. incomplete or asymmetrical in various ways.
  103.    Propagation is never done unattended.  The user on a site has to call
  104. `remsync broadcast' to issue synchronization packages for other sites.
  105. If this is never done, the local modifications will never leave the
  106. site.  The user also has to call `remsync process' to apply received
  107. synchronization packages.  Applying a package does not automatically
  108. broadcast it further (maybe this could change?).
  109.    If a site A propagates some files to sites B and D, but not C, site
  110. B is informed that site D also received these files, and site D is
  111. informed that site B also received these files, so they will not
  112. propagate again the same files to one another.  However, both site B
  113. and D are susceptible to propagate further the same files to site C.
  114.    It may happen that a site refuses to update a file, or modifies a
  115. file after having been received, or merges versions, or whatever.  So,
  116. sites may have a wrong opinion of the file contents on other sites.
  117. These differences level down after a few exchanges, and it is very
  118. unlikely that a file would not be propagated when it should have.
  119.    This scheme works only when the various people handling the various
  120. files have confidence in one each other.  If site B modifies a file
  121. after having received it from site A, the file will eventually be
  122. propagated back to site A.  If the original file stayed undisturbed on
  123. site A, that is, if `remsync' proves that site B correctly knew the
  124. checksum of the original file, then the file will be replaced on site A
  125. without any user confirmation.  So, the user on site A has to trust the
  126. changes made by the user on site B.
  127.    If the original file on site A had been modified after having been
  128. sent in a synchronization package, than it is the responsibility of the
  129. user on site A to correctly merge the local modifications with the
  130. modifications observed in the file as received from site B.  This
  131. responsibility is real, since the merged file will later be propagated
  132. to the other sites in an authoritative way.
  133. File: remsync.info,  Node: Quick start,  Prev: Internals,  Up: Overview
  134. Quick start at using `remsync'
  135. ==============================
  136. File: remsync.info,  Node: Remsync,  Next: Services,  Prev: Overview,  Up: Top
  137. Specifications of program `remsync'
  138. ***********************************
  139. * Menu:
  140. * Invoking remsync::    The `remsync' command and arguments
  141. * Conveniences::        Automatic mechanisms in the `remsync' program
  142. * Commands::            Commands for `remsync'
  143. File: remsync.info,  Node: Invoking remsync,  Next: Conveniences,  Prev: Remsync,  Up: Remsync
  144. The `remsync' command and arguments
  145. ===================================
  146.    At the shell prompt, calling the command `remsync' without any
  147. parameters initiates an interactive dialog, in which the user types
  148. commands and receives feedback from the program.
  149.    The command `remsync', given at the shell prompt, may have
  150. arguments, in which case these arguments taken together form one
  151. `remsync' interactive command.  However, `--help' and `--version'
  152. options are interpreted especially, with their usual effect in GNU.
  153. Once this command has been executed, no more commands are taken from
  154. the user and `remsync' terminates execution.  This allows for using
  155. `remsync' in some kind of batch mode.  It is unwise to redirect
  156. `remsync' standard input, because user interactions might often be
  157. needed in ways difficult to predict in advance.
  158.    The two most common usages of `remsync' are the commands:
  159.      remsync b
  160.      remsync p
  161.    The first example executes the `broadcast' command, which sends
  162. synchronization packages to all connected remote sites for the current
  163. local directory tree.
  164.    The second example executes the `process' command, which studies and
  165. complies with a synchronisation package saved in the current directory
  166. (not necessarily into the synchronized directory tree), under the usual
  167. file name `remsync.tar.gz'.
  168. * Menu:
  169. * Conveniences::        Automatic mechanisms in the `remsync' program
  170. * Commands::            Commands for `remsync'
  171. File: remsync.info,  Node: Conveniences,  Next: Commands,  Prev: Invoking remsync,  Up: Remsync
  172. Automatic mechanisms in the `remsync' program
  173. =============================================
  174.    The following points apply to many of the `remsync' commands.  We
  175. describe them here once and for all.
  176.    * The file `.remsync' describes the various properties for the
  177.      current synchronization.  It is kept right in the top directory of
  178.      a synchronized directory tree.  Some commands may be executed
  179.      without any need for this file.  The program waits as far as
  180.      possible before reading it.
  181.    * If the `.remsync' file is not found when required, and only then,
  182.      the user is interactively asked to fill a questionnaire about it.
  183.    * If the `.remsync' file has been logically modified after having
  184.      been read, or if it just has been created, the program will save
  185.      it back on disk.  But it will do so only before reading another
  186.      `.remsync' file, or just before exit.  A preexisting `.remsync'
  187.      will be renamed to `.remsync.bak' before it is rewritten, when
  188.      this is done, any previous `.remsync.bak' file is discarded.
  189.    * Many commands refer to previously entered information by repeating
  190.      this information.  For example, one can refer to a particular
  191.      `scan' statement by entering the wildcard to be scanned by this
  192.      statement.  An alternative method of specifying a statement
  193.      consists in using the decimal number which appears between square
  194.      brackets in the result of a `list' command.
  195.    * Whenever a site list must be given, it is a space separated list of
  196.      remote sites.  If the list is preceeded by a bang (<!>), the list
  197.      is complemented, that is, the sites that will be operated upon are
  198.      all those *not* appearing in the list.  As a special case, if the
  199.      site list is completely empty, then all sites are selected.
  200. File: remsync.info,  Node: Commands,  Prev: Conveniences,  Up: Remsync
  201. Commands for `remsync'
  202. ======================
  203.    Program commands to `remsync' may be given interactively by the user
  204. sitten at a terminal.  They can come from the arguments of the
  205. `remsync' call at the shell level.  Internally, the `process' command
  206. might obey many sub-commands found in a received synchronization
  207. package.
  208.    Program commands are given one per line.  Lines beginning with a
  209. sharp (<#>) and white lines are ignored, they are meant to increase
  210. clarity or to introduce user comments.  With only a few exceptions,
  211. commands are introduced by a keyword and often contains other keywords.
  212. In all cases, the keywords specific to `remsync' may be abbreviated to
  213. their first letter.  When there are many keywords in succession, the
  214. space separating them may be omitted.  So the following commands are
  215. all equivalent:
  216.      list remote
  217.      l remote
  218.      list r
  219.      l r
  220.      listremote
  221.      lr
  222. while the following are not legal:
  223.      l rem
  224.      lisremote
  225.    Below, for clarity, keywords are written in full and separated by
  226. spaces.  Commands often accept parameters, which are then separated by
  227. spaces.  All available commands are given in the table.  The first few
  228. commands do not pre-require the file `.remsync'.  The last three
  229. commands are almost never used interactively, but rather automatically
  230. triggered while `process''ing received synchronization packages.
  231.      Display a quick help summary of available commands.
  232. `!' [ SHELL-COMMAND ]
  233.      If SHELL-COMMAND has been given, execute it right now as a shell
  234.      command.  When not given, rather start an interactive shell.
  235.      Exiting from the shell will return to this program.  The started
  236.      shell is taken from the `SHELL' environment variable if set, else
  237.      `sh' is used.
  238. `quit'
  239.      Leave the program normally and return to the shell.
  240. `abort'
  241.      Leave the program with a nonzero exit status and return to the
  242.      shell.  No attempt is made to save a logically modified `.remsync'
  243.      file.
  244. `visit' DIRECTORY
  245.      Select another synchronized directory tree for any subsequent
  246.      operation.  DIRECTORY is the top directory of the synchronized
  247.      directory tree.
  248. `process' [ FILE ]
  249. `list' [ TYPE ]
  250.      List all known statements about some information TYPE.  Allowable
  251.      keywords for TYPE are `local', `remote', `scan', `ignore' and
  252.      `files'.  The keyword `files' asks for all empty statements (see
  253.      later).  If TYPE is omitted, then list all known statements for
  254.      all types, except those given by `files'.
  255. [ `create' ] TYPE VALUE
  256.      Create a new statement introducing a VALUE for a given TYPE.
  257.      Allowable keywords for TYPE are `remote', `scan' and `ignore'.
  258.      The `create' keyword may be omitted.
  259.      For `create' `ignore', when the pattern is preceeded by a bang
  260.      (<!>), the condition is reversed.  That is, only those files which
  261.      do match the pattern will be kept for synchronization.
  262. `delete' TYPE VALUE
  263.      Delete an existing statement supporting some VALUE for a given
  264.      TYPE.  Allowable keywords for TYPE are `remote', `scan' and
  265.      `ignore'.
  266. `email' REMOTE VALUE
  267.      Modify the electronic mail address associated with some REMOTE
  268.      site, giving it a new VALUE.  The special `local' keyword for
  269.      REMOTE may be used to modify the local electronic mail address.
  270. `home' REMOTE VALUE
  271.      Modify the top directory of the synchronized directory tree
  272.      associated with some REMOTE site, giving it a new VALUE.  The
  273.      special `local' keyword for REMOTE may be used to modify the local
  274.      top directory.
  275. `broadcast' SITE_LIST
  276.      Send by electronic mail an update package to all sites from
  277.      SITE_LIST, containing for each site all and only those files which
  278.      are known to be different between the remote site and here.
  279. `version' VERSION
  280.      This command is not meant for interactive use.  It establishes the
  281.      `remsync' version needed to process the incoming commands.
  282. `from' SITE_LIST
  283.      This command is not really meant for interactive use.  The first
  284.      site from the SITE_LIST is the remote site which originated the
  285.      synchronization package.  All the others are all the sites,
  286.      including here, which were meant to be synchronized by the
  287.      `broadcast' command that was issued at the originating remote site.
  288. `sum' FILE CHECKSUM
  289.      This command is not really meant for interactive use.  It declares
  290.      the CHECKSUM value of a particular FILE at the originating remote
  291.      site.  Also, if at least one `sum' command is received, then it is
  292.      guaranteed that the originating remote site sent one `sum' command
  293.      for each and every file to be synchronized, so any found local
  294.      file which was not subject of any `sum' command does not exist
  295.      remotely.
  296. `if' FILE CHECKSUM PACKAGED
  297.      This command is not really meant for interactive use.  It directs
  298.      the `remsync' program to check if a local FILE has a given
  299.      CHECKSUM.  If the checksum agrees, then the local file will be
  300.      replaced by the PACKAGED file, as found in the received
  301.      synchronization invoice.
  302. File: remsync.info,  Node: Services,  Next: Formats,  Prev: Remsync,  Up: Top
  303. Specifications of other service programs
  304. ****************************************
  305. * Menu:
  306. * Invoking mailshar::   The `mailshar' command and arguments
  307. * Invoking mail-files::  The `mail-files' command and arguments
  308. * Invoking find-mailer::  The `find-mailer' command and arguments
  309. File: remsync.info,  Node: Invoking mailshar,  Next: Invoking mail-files,  Prev: Services,  Up: Services
  310. The `mailshar' command and arguments
  311. ====================================
  312. File: remsync.info,  Node: Invoking mail-files,  Next: Invoking find-mailer,  Prev: Invoking mailshar,  Up: Services
  313. The `mail-files' command and arguments
  314. ======================================
  315. File: remsync.info,  Node: Invoking find-mailer,  Prev: Invoking mail-files,  Up: Services
  316. The `find-mailer' command and arguments
  317. =======================================
  318. File: remsync.info,  Node: Formats,  Next: Miscellaneous,  Prev: Services,  Up: Top
  319. Related file formats
  320. ********************
  321. * Menu:
  322. * Xremsync::            Format of the `.remsync' file
  323. * Package::             Format of transiting packages
  324. File: remsync.info,  Node: Xremsync,  Next: Package,  Prev: Formats,  Up: Formats
  325. Format of the `.remsync' file
  326. =============================
  327.    The `.remsync' file saves all the information a site needs for
  328. properly synchronizing a directory tree with remote sites.  Even if it
  329. is meant to be editable using any ASCII editor, it has a very precise
  330. format and one should be very careful while modifying it.  The
  331. `.remsync' file is better handled through the `remsync' program and
  332. commands.
  333.    The `.remsync' file is made up of statements, one per line.  Each
  334. line begins with a statement keyword followed by a single <TAB>, then
  335. by one or more parameters.  The keyword may be omitted, in this case,
  336. the keyword is said to be *empty*, and the line begins immediately with
  337. the <TAB>.  After the <TAB>, if there are two parameters or more, they
  338. should all be separated with a single space.  There should not be any
  339. space between the last parameter and the end of line (unless there are
  340. explicit empty parameters).
  341.    The following table gives the possible keywords.  Their order of
  342. presentation in the table is also the order of appearance in the
  343. `.remsync' file.
  344. `remsync'
  345.      This statement identifies the `.remsync' format.  The only
  346.      parameter states the file format version.
  347. `local'
  348.      This statement should appear exactly once, and has exactly two
  349.      parameters.  The first parameter gives the electronic mail address
  350.      the other sites should use for sending synchronization packages
  351.      here.  The second parameter gives the name of the local directory
  352.      tree to synchronize, in absolute notation.
  353. `remote'
  354.      This statement may appear zero, one or more times.  Each occurrence
  355.      connects the synchronized directory tree to another tree on a
  356.      remote site.  The first parameter gives one electronic mail
  357.      address where to send remote synchronization packages.  The second
  358.      parameter gives the name of the corresponding directory tree for
  359.      this remote electronic mail address, in absolute notation.
  360. `scan'
  361.      This statement may appear zero, one or more times.  When it does
  362.      not appear at all, the whole local directory tree will always be
  363.      scanned, searching for files to synchronize.  When the statement
  364.      appears at least once, the whole local directory tree will not be
  365.      scanned, but only those files or directories appearing in one of
  366.      these statements.  Each `scan' statement has exactly one
  367.      parameter, giving one file or directory to be studied.  These are
  368.      usually given relative to top directory of the local
  369.      synchronization directory tree.  Shell wildcards are acceptable.
  370. `ignore'
  371.      This statement may appear zero, one or more times.  Each
  372.      occurrence has one parameter giving a regular expression,
  373.      according to Perl syntax for regular expressions.  These REGEXPs
  374.      are applied against each file resulting from the scan.  If any of
  375.      the `ignore' expression matches one of resulting file, the file is
  376.      discarded and is not subject to remote synchronization.
  377.    After all the statements beginning by the previous keywords, the
  378. `.remsync' file usually contains many statements having the empty
  379. keyword.  The empty keyword statement may appear zero, one or more
  380. times.  Each occurrence list one file being remotely synchronized.  The
  381. first parameter gives an explicit file name, usually given relative to
  382. the top directory of the local synchronized directory tree.  Shell
  383. wildcards are *not* acceptable.
  384.    Besides the file name parameter, there are supplementary parameters
  385. to each empty keyword statement, each corresponding to one remote
  386. statement in the `.remsync' file.  The second parameter corresponds to
  387. the first remote, the third parameter corresponds to the second remote,
  388. etc.  If there are more remote statements than supplementary parameters,
  389. missing parameters are considered to be empty.
  390.    Each supplementary parameter usually gives the last known checksum
  391. value for this particular file, as computed on its corresponding
  392. *remote* site.  The parameter contains a dash `-' while the remote
  393. checksum is unknown.  The checksum value for the *local* copy of the
  394. file is never kept anywhere in the `.remsync' file.  The special value
  395. `666' indicates a checksum from hell, used when the remote file is
  396. known to exist, but for which contradictory information has been
  397. received from various sources.
  398. File: remsync.info,  Node: Package,  Prev: Xremsync,  Up: Formats
  399. Format of transiting packages
  400. =============================
  401. File: remsync.info,  Node: Miscellaneous,  Prev: Formats,  Up: Top
  402. Various considerations
  403. **********************
  404. * Menu:
  405. * News::                Using News distribution instead?
  406. * Previous::            Documentation for obsolete scripts
  407. File: remsync.info,  Node: News,  Next: Previous,  Prev: Miscellaneous,  Up: Miscellaneous
  408. Using News distribution instead?
  409. ================================
  410.    One correspondent thinks that perhaps the news distribution mechanism
  411. could be pressed into service for this job.  I could have started from
  412. C-news, say, instead of from scratch, and have progressively bent
  413. C-news to behave like I wanted.
  414.    My feeling is that the route was shorter as I did it, from scratch,
  415. that it would have been from C-news.  Of course, I could have removed
  416. the heavy administrative details of C-news: the history and `expire',
  417. the daemons, the `cron' entries, etc., then added the interactive
  418. features and specialized behaviors, but all this clean up would
  419. certainly have took energies.  Right now, non counting the subsidiary
  420. scripts and shar/unshar sources, the heart of the result is a single
  421. (1200 lines) script written in Perl, which I find fairly more smaller
  422. and maintainable than a patched C-news distribution would have been.
  423. File: remsync.info,  Node: Previous,  Prev: News,  Up: Miscellaneous
  424. Documentation for obsolete scripts
  425. ==================================
  426.    This is merely a place holder for previous documentation, waiting
  427. that I clean it up.  You have no interest in reading further down.
  428. * Menu:
  429. * mailsync::            mailsync
  430. * resync::              resync
  431. File: remsync.info,  Node: mailsync,  Next: resync,  Prev: Previous,  Up: Previous
  432. mailsync
  433. --------
  434.      Usage: mailsync [ OPTION ] ... [ EMAIL_ADDRESS ] [ DIRECTORY ]
  435.         or: mailsync [ OPTION ] ... SYNC_DIRECTORY
  436.    Option -i simply sends a `ihave' package, with no bulk files.
  437. Option -n inhibits any destructive operation and mailing.
  438.    In the first form of the call, find a synchronisation directory in
  439. DIRECTORY aimed towards some EMAIL_ADDRESS, then proceed with this
  440. synchronisation directory.  EMAIL_ADDRESS may be the name of a file
  441. containing a distribution list.  If EMAIL_ADDRESS is not specified, all
  442. the synchronisation directories at the top level in DIRECTORY are
  443. processed in turn.  If DIRECTORY is not specified, the current
  444. directory is used.
  445.    In the second form of the call, proceed only with the given
  446. synchronisation directory SYNC_DIRECTORY.
  447.    For proceeding with a synchronisation directory, whatever the form of
  448. the call was, this script reads the `ident' files it contains to set
  449. the local user and directory and the remote user and directory.  Then,
  450. selected files under the local directory which are modified in regard
  451. to the corresponding files in the remote directory are turned into a
  452. synchronisation package which is mailed to the remote user.
  453.    The list of selected files or directories to synchronize from the
  454. local directory are given in the `list' file in the synchronisation
  455. directory.  If this `list' file is missing, all files under the local
  456. directory are synchronized.
  457.    What I usually do is to `cd' at the top of the directory tree to be
  458. synchronized, then to type `mailsync' without parameters.  This will
  459. automatically prepare as many synchronisation packages as there are
  460. mirror systems, then email multipart shars to each of them.  Note that
  461. the synchronisation package is not identical for each mirror system,
  462. because they do not usually have the same state of synchronisation.
  463.    `mailsync' will refuse to work if anything needs to be hand cleaned
  464. from a previous execution of `mailsync' or `resync'.  Check for some
  465. remaining `_syncbulk' or `_synctemp' directory, or for a `_syncrm'
  466. script.
  467.      TODO:
  468.      - interrogate the user if `ident' file missing.
  469.      - automatically construct the local user address.
  470.      - create the synchronisation directory on the fly.
  471.      - avoid duplicating work as far as possible for multiple sends.
  472.      - have a quicker mode, depending on stamps, not on checksums.
  473.      - never send core, executables, backups, `.nsf*', `*/_synctemp/*', etc.
  474. File: remsync.info,  Node: resync,  Prev: mailsync,  Up: Previous
  475. resync
  476. ------
  477.      Usage: resync [ OPTION ]... TAR_FILE
  478.         or: resync [ OPTION ]... UNTARED_DIRECTORY
  479.    Given a tar file produced by mailsync at some remote end and already
  480. reconstructed on this end using unshar, or a directory containing the
  481. already untared invoice, apply the synchronization package locally.
  482.    Option -n inhibits destroying or creating files, but does everything
  483. else.  It will in particular create a synchronization directory if
  484. necessary, produce the `_syncbulk' directory and the `_syncrm' script.
  485.    The synchronization directory for the package is automatically
  486. retrieved or, if not found, created and initialized.  `resync' keeps
  487. telling you what it is doing.
  488.    There are a few cases when a resync should not complete without
  489. manual intervention.  The common case is that several sites update the
  490. very same files differently since they were last resync'ed, and then
  491. mailsync to each other.  The prerequisite checksum will then fail, and
  492. the files are then kept into the `_syncbulk' tree, which has a shape
  493. similar to the directory tree in which the files where supposed to go.
  494. For GNU Emacs users, a very handy package, called emerge, written by
  495. Dale Worley <drw@kutta.mit.edu>, helps reconciling two files
  496. interactiveley.  The `_syncbulk' tree should be explicitely deleted
  497. after the hand synchronisation.
  498.    Another case of human intervention is when files are deleted at the
  499. mailsync'ing site.  By choice, all deletions on the receiving side are
  500. accumulated in a `_syncrm' script, which is not executed automatically.
  501. Explicitely executed, `_syncrm' will remove any file in the receiving
  502. tree which does not exist anymore on the sender system.  I often edit
  503. `_syncrm' before executing it, to remove the unwanted deletions (beware
  504. the double negation :-).  The script removes itself.
  505.    All the temporary files, while resynchronizing, are held in
  506. `_synctemp', which is deleted afterwards; if something goes wrong, this
  507. directory should also be cleaned out by hand.  `resync' will refuse to
  508. work if anything remains to be hand cleaned.
  509.      TODO:
  510.      - interrogates the user if missing receiving directory in `ident'.
  511.      - allow `remote.sum' to be empty or non-existent.
  512. Tag Table:
  513. Node: Top
  514. Node: Overview
  515. Node: Internals
  516. Node: Quick start
  517. Node: Remsync
  518. Node: Invoking remsync
  519. Node: Conveniences
  520. Node: Commands
  521. 11396
  522. Node: Services
  523. 16557
  524. Node: Invoking mailshar
  525. 16922
  526. Node: Invoking mail-files
  527. 17105
  528. Node: Invoking find-mailer
  529. 17304
  530. Node: Formats
  531. 17479
  532. Node: Xremsync
  533. 17727
  534. Node: Package
  535. 22155
  536. Node: Miscellaneous
  537. 22285
  538. Node: News
  539. 22528
  540. Node: Previous
  541. 23552
  542. Node: mailsync
  543. 23906
  544. Node: resync
  545. 26458
  546. End Tag Table
  547.